This document describes how Internet Service Providers can use the CommuniGate System to implement E-mail services that their customers may need. Please read the "Internet E-mail using Dial-up connection" document to learn about the various types of E-mail connectivity you can provide.
UUCP Links
If some of your clients use UUCP links, you need the UUCPGate. Register one UUCP host for each client that connects to you directly via a modem. If you assign domain names yourself, it may be useful to give each UUCP system a domain name that starts with the uucp system name you gave to that system: something like uucpsystem.uucp.domain.com. In this case, you'll need only one line in your Routing settings to route mail to all of your UUCP customers:
*.uucp.domain.com = *.uucp
The "Use this host as Mail Server" option should NOT be selected in the customer UUCP host descriptors.
Hosting Customer Domains
If your customer mail should go to or through your CommuniGate Server, make sure that all mail to the customer domain is directed to your server. Usually this can be done with the Domain Name System (DNS): your server domain name should be included into the so-called MX records describing the customer domain.
Direct Mapping of Customer Domains
The simplest method to serve your customer domain is to map it on your own domain. For example, if your domain is provider.com, and your customer has a domain customer1.com, you can enter one line per customer in the Router table of your CommuniGate Server:
customer1.com = provider.com
customer2.com = provider.com
In this case all mail to the customer1.com domain received with your server will be treated as mail sent to your own, provider.com domain, i.e. mail sent to user1@customer1.com will end up in the user1 account on your system.
This solution is the simplest one and it can be used if there is only one or few accounts in the customer domain. You have to create those accounts on YOUR system. Usually your customers cannot connect to your server directly via AppleTalk, so they will use various TCP/IP links and POP-based mailers (Eudora, Fog City Emailer, Cyberdog, etc.). To allow your customers to retrieve mail from their accounts on your server, you should log into those accounts with the CommuniGator application and fill the POP Access setting (password) in the User Settings.
This solution has a problem: since all accounts are actually accounts on YOUR server, in YOUR domain, it is impossible to create the same accounts for two customers: in the sample above, it is not possible to use the addresses sales@customer1.com and sales@customer2.com - you can create only one sales account on your system, and mail sent to both accounts will end up in that single account.
Merged Mapping of Customer Accounts
If you want to host many customer accounts on your server, you can solve the problem mentioned above by creating "merged" accounts - accounts with names composed of a user name and a domain name (or any other unique name).
For example, if you have customers with the domains customer1.com and customer2.com, then you can enter the following lines in your Router:
customer1.com = cs1%merge
customer2.com = cs2%merge
In this case mail to info@customer1.com will go to the account info.cs1 (note the dot sign) that you should create on your server, mail to sales@customer1.com will go to the account sales.cs1, while mail to info@customer2.com will go to the info.cs2 account on your system. After you have created the info.cs1, sales.cs1, info.cs2, sales.cs2, etc. accounts on your system, you should use the CommuniGator application to log into these accounts, and to enable remote POP access.
Please note that your customers have to enter sales.cs1@provider.com, info.cs2@provider.com strings into the POP Account setting of their mailers. This can create a problem: some mailers always use the POP Account setting for the From field of the messages they compose. In this case the messages sent by your customers will have the header with the From:info.cs1@provider.com field, instead of the From:info@customer1.com field. This will make customer domain names useless. Make sure that your customers use mailers that allow them to specify the POP Account AND the From field separately. For example, Eudora Lite allows them to specify the From field separately (it is called "Return Address" in its Settings).
The only problem with this solution is the number of the accounts you have to create. For 20 customer domains with 5 accounts on each, you have to create 100 accounts on your system.
Unified Domain-wide Accounts
If your customer has their own domain name, you can consider creating a so-called Unified-Domain Wide account. When any mail comes to the customer domain, it is stored in one account on your system, with the "username" part of an E-mail address ignored: all messages to info@customer1.com, sales@customer1.com, abc@customer1.com, etc. are stored in one account on your CommuniGate Server. You may offer such an account if a customer agrees to download mail from that account and to sort it manually, or if a customer has software that can process Unified Domain-Wide accounts automatically (as the CommuniGate POPGate in the client mode).
To create Unified Domain-Wide accounts for the domains customer1.com and customer2.com, put the following lines into the Router table:
customer1.com = customer1.com%cc1
cc1 = <localgate>cs1
customer2.com = customer2.com%cc2
cc2 = <localgate>cs2
This scheme uses 2 lines per domain in order to keep the original domain name in the converted address. The converted address will be sent as the "X-Real-To:" Header when the customer retrieves mail from the Unified account using the POP protocol. If you do not need to include the original domain name into those headers, you may use one line per domain:
customer1.com = <localgate>cs1
customer2.com = <localgate>cs2
As with regular individual accounts, you have to register the cs1 and cs2 accounts with your CommuniGate Server and then you should enable remote POP access to these accounts. When your customers fill the POP Account setting in their POP mailers, they should use cs1@provider.com and cs2@provider.com strings, where provider.com is your domain name.
If your customers use the CommuniGate POPGate, they should use these strings in their POPGate Service Settings, in the Unified Domain-Wide Account field.
Serving Customer Systems via SMTP
If your customers have direct (permanent) links to the Internet, they do not need any special support from your mail server. Just check that your CommuniGate Server is included into the MX records of the customer system as a lower-priority relay, so when that system is down all its mail is collected on your server. There is no need to register any account on your s
ystem or to enter anything into your Router table in order to support these customers.
You can avoid using POP accounts even for your dial-up customers, if they can receive mail via SMTP. As for directly-connected customers, your CommuniGate Server should be included into the MX records of the customer system, so when the customer system is not linked to the Internet all its mail is collected on your server.
The CommuniGate SMTPGate supports the RFC1985 "Remote Queue Starting" mechanism in the server mode, so your customers should have SMTP software that supports the RFC1985 mechanism in the client mode. This means that the customer software should link to the Internet, connect to your SMTPGate and then it should send a special command described in the RFC1985 document. This will force the SMTPGate on your system to release the queue of the messages directed to the customer host. For example, your customers can use the SMTPGate software, too - The SMTPGate supports the RFC1985 mechanism in the client mode.
You do not have to do anything with the Router table, and you do not have to register any account on your system in order to support dial-up customers with E-mail software that supports RFC1985 - mail is delivered automatically as with the customers that use direct links to the Internet.
